Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow function pointers to #[rustc_args_required_const] #48078

Merged
merged 2 commits into from
Feb 10, 2018

Conversation

alexcrichton
Copy link
Member

This commit disallows acquiring a function pointer to functions tagged as
#[rustc_args_required_const]. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.

Note that the first commit here isn't related specifically to this feature, but was necessary to get this working in stdsimd!

@rust-highfive
Copy link
Collaborator

r? @michaelwoerister

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

r? @eddyb

Thanks again for your excellent instructions here! To confirm we at least don't need this for stdsimd today in terms of methods, just free functions for intrinsics. (methods may come at a later date maybe though?)

span: Span) {
// We're only interested in functions tagged with
// #[rustc_args_required_const], so ignore anything that's not.
if !self.tcx.get_attrs(def_id).iter().any(|a| a.check_name("rustc_args_required_const")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be !self.tcx.has_attr(def_id, "rustc_args_required_const")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed!

Unfortunately left out it means that when the `#![feature(proc_macro)]` flag is
in effect it fails to find `rustc_args_required_const` for expansion. This
version, however, is verified to work with stdsimd's requirements!
@alexcrichton alexcrichton force-pushed the fix-required-const-and-proc-macro branch from ba31f4f to b5475af Compare February 8, 2018 21:39
@arazabishov arazabishov added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 8, 2018
@eddyb
Copy link
Member

eddyb commented Feb 8, 2018

@alexcrichton Oh, what I was thinking wrt methods is irrelevant - you can't "extract" the method as a value any other way than using a value path - so your check here would work fine even then.

}

self.tcx.sess.span_err(span, "this function can only be invoked \
directly, not through a function pointer");
Copy link
Member

@eddyb eddyb Feb 8, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you generalize this a bit?

Some context: foo(0) works but let f = foo; f(0) doesn't, even if it doesn't become a function pointer (if we allow the latter, we can't prevent let f = foo; f(0); f(1) easily/at all, which is the scary hazard, typesystem-wise).

So, "this function can only be called directly, not used as a value or called through a function pointer".

half an hour later okay maybe we can just keep your version, if it's confusing for anyone we can change it later.

@eddyb
Copy link
Member

eddyb commented Feb 8, 2018

@alexcrichton Okay, I think the only change I want on this is a sanity check in case we screw up:

mir::CastKind::ReifyFnPointer => {
match operand.layout.ty.sty {
ty::TyFnDef(def_id, substs) => {

mir::CastKind::ReifyFnPointer => {
match operand.ty.sty {
ty::TyFnDef(def_id, substs) => {

ReifyFnPointer => {
match self.eval_operand(operand)?.ty.sty {
ty::TyFnDef(def_id, substs) => {

Those 3 places implement the reification to a fn pointer - can you add a span_bug! for the case when the attribute is present on def_id? Just so we ICE instead of doing the wrong thing.

@alexcrichton alexcrichton force-pushed the fix-required-const-and-proc-macro branch from b5475af to 5de8e19 Compare February 8, 2018 22:41
@alexcrichton
Copy link
Member Author

@bors: r=eddyb

Thanks again so much for the detailed help @eddyb!

@bors
Copy link
Contributor

bors commented Feb 8, 2018

📌 Commit 5de8e19 has been approved by eddyb

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 8, 2018
This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.
@alexcrichton alexcrichton force-pushed the fix-required-const-and-proc-macro branch from 5de8e19 to 7a20fc1 Compare February 8, 2018 22:46
@alexcrichton
Copy link
Member Author

@bors: r=eddyb

@bors
Copy link
Contributor

bors commented Feb 8, 2018

📌 Commit 7a20fc1 has been approved by eddyb

kennytm added a commit to kennytm/rust that referenced this pull request Feb 9, 2018
…-proc-macro, r=eddyb

Disallow function pointers to #[rustc_args_required_const]

This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.

Note that the first commit here isn't related specifically to this feature, but was necessary to get this working in stdsimd!
bors added a commit that referenced this pull request Feb 9, 2018
Rollup of 12 pull requests

- Successful merges: #47835, #47854, #48015, #48047, #48051, #48058, #48064, #47790, #48059, #48078, #48080, #48085
- Failed merges:
@alexcrichton
Copy link
Member Author

@bors: rollup

kennytm added a commit to kennytm/rust that referenced this pull request Feb 9, 2018
…-proc-macro, r=eddyb

Disallow function pointers to #[rustc_args_required_const]

This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.

Note that the first commit here isn't related specifically to this feature, but was necessary to get this working in stdsimd!
bors added a commit that referenced this pull request Feb 9, 2018
Rollup of 17 pull requests

- Successful merges: #47790, #47835, #47854, #48015, #48047, #48051, #48058, #48059, #48064, #48078, #48080, #48085, #48086, #48090, #48093, #48098, #48101
- Failed merges:
kennytm added a commit to kennytm/rust that referenced this pull request Feb 10, 2018
…-proc-macro, r=eddyb

Disallow function pointers to #[rustc_args_required_const]

This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.

Note that the first commit here isn't related specifically to this feature, but was necessary to get this working in stdsimd!
bors added a commit that referenced this pull request Feb 10, 2018
Rollup of 16 pull requests

- Successful merges: #47790, #47835, #47854, #48015, #48047, #48051, #48058, #48059, #48064, #48078, #48080, #48086, #48098, #48101, #48107, #48100
- Failed merges:
bors added a commit that referenced this pull request Feb 10, 2018
@bors bors merged commit 7a20fc1 into rust-lang:master Feb 10, 2018
@alexcrichton alexcrichton deleted the fix-required-const-and-proc-macro branch February 26, 2018 23:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants